Skip to content

P4 Stage 1: zunifikuj parsowanie błędów PBN przez ErrorRecord#611

Merged
mpasternak merged 14 commits into
devfrom
feat/pbn-p4-reader
Jul 24, 2026
Merged

P4 Stage 1: zunifikuj parsowanie błędów PBN przez ErrorRecord#611
mpasternak merged 14 commits into
devfrom
feat/pbn-p4-reader

Conversation

@mpasternak

Copy link
Copy Markdown
Member

Cel

Cztery rozproszone, kruche parsery błędów wysyłki do PBN (format_pbn_error,
parse_pbn_api_error, parse_error_details, admin exception_details) →
cienkie adaptery nad jednym kontraktem ErrorRecord.

Rdzeń (ErrorRecord + parse + serialize) mieszka w pakiecie pbn-client
(0.2.1) jako czysta wiedza o protokole — patrz iplweb/pbn-client#7. W BPP
zostają tylko Django-owe adaptery display.

Rollout reader-first (Stage 1)

Readery rozumieją legacy ORAZ format v1; writery bez zmian.
serialize() istnieje, ale nie jest podpięty (Stage 2 — dopiero po wdrożeniu
Stage 1 na całej flocie). To eliminuje deploy-race przy przełączaniu writerów.

Byte-identyczność

Golden testy charakteryzacyjne (test_error_record_golden.py + fixture
data/error_record_golden.json) zdjęte z outputu sprzed unifikacji pinują
byte-identyczność realistycznego legacy (per-funkcja, na jej realnej domenie
wejścia). Świadome ulepszenia: koniec crasha TypeError na payloadzie-liczbie;
koniec hacka split('"details":')[1][:-3] w adminie.

Recenzje adwersaryjne (2× Fable) — naprawione

  • Reader-first dla v1: bez pola wire readery klasyfikowały blob v1 jako
    „nie-PBN" / renderowały surowy JSON → Stage 1 nie kupował ochrony. Naprawione
    • pinowane test_error_record_v1_reader.py.
  • Totalność parse(): RecursionError/OverflowError/MemoryError.
  • Konflacja JSON null ↔ niepoprawny body: pole content_json_valid.
  • serialize(): capy na wszystkie pola.

Rozliczenie findingów: docs/deweloper/p4-error-record-unifikacja-spec.md §9.

Zależność / merge order

[tool.uv.sources] pinuje pbn-client git-source do commita gałęzi
feat/error-record (pakiet PUBLIC, CI go pobierze). Po wydaniu pbn-client
0.2.1 na PyPI
usunąć wpis z [tool.uv.sources] — pin >=0.2.1,<0.3
wystarczy. Merge dopiero po iplweb/pbn-client#7.

Testy

Pełne pbn_export_queue + pbn_api: 601 passed (w tym playwright admin
changelist renderujący exception_details). ruff + manage.py check czyste.

Stack: na feat/pbn-shims (#609).

🤖 Generated with Claude Code

mpasternak and others added 12 commits July 14, 2026 20:27
Atrybut wiążący model w getterach stron PBN niósł nazwę z monorepo
(pbn_api). Ujednolicony z pakietem django-pbn-client: baza deklaruje
class-attr `model_class = None`, konstruktor nie przesłania go None-em,
a InstitutionGetter/ZrodlaGetter/PublisherGetter oraz shim
ThreadedMongoDBSaver używają nowej nazwy.

manage.py check: OK; pakiet + test_helpers: 40 passed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ges/

Krok 1 planu ekstrakcji: BPP konsumuje pbn-client i django-pbn-client jako
normalne zależności z PyPI (0.1.0, github.com/iplweb/*) zamiast lokalnych
memberów uv workspace.

- usunięto katalog packages/ (kopie robocze) — źródłem jest teraz PyPI,
- pyproject: usunięto [tool.uv.workspace] i wpisy `{ workspace = true }`
  z [tool.uv.sources] (django-import-export git-source zostaje); deps
  pbn-client/django-pbn-client bez zmian,
- pytest.ini: testpaths = src (bez packages),
- Dockerfile: usunięto 4× `COPY packages/` (obraz nie ma już tego katalogu),
- .dockerignore: usunięto regułę README paczek,
- uv.lock: przeliczony (paczki z indeksu, nie editable).

Weryfikacja: paczki zainstalowane z PyPI (==0.1.0, nie editable);
manage.py check OK; makemigrations --check bez dryfu w pbn_api/django_pbn_client
(pozostały dryf to pre-existing third-party AutoField: favicon/flexible_reports/
siteblog); test_helpers + test_validators 31 passed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- pbn-client / django-pbn-client: >=0.2,<0.3 (wave 0.2 z PyPI), uv.lock przeliczony,
- przepisany docs/deweloper/pakiety-pbn.md: architektura PyPI zamiast workspace
  (usunięty opis packages/ + Docker copy + komend na nieistniejące ścieżki),
- zaktualizowane docs/deweloper/index.md i newsfragment,
- usunięte 48 nieaktualnych wpisów packages/* z .test_durations.

Weryfikacja: manage.py check OK; makemigrations --check bez dryfu pbn;
test_helpers + test_validators 31 passed na paczkach 0.2.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pbn-client 0.2 przemianował parametr konstruktora publication_pk -> correlation_id
(z property publication_pk do odczytu, ale nie jako kwarg konstruktora).
Test kolejki konstruował wyjątek z publication_pk= -> TypeError. Adopcja
nowej nazwy w teście.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…wnload

- 6 modeli PBN (journal, institution, publisher, publication, scientist,
  conference) używa property `is_deleted` z BasePBNMongoDBModel zamiast
  magic-stringa `status == "DELETED"` (marker „[❌ USUNIĘTY]" bez zmian)
- `check_mongoId` deleguje do `pbn_client.is_valid_object_id`
  (ta sama semantyka: 24-znakowy hex objectId)
- `ensure_publication/person/institution_exists` delegują do
  `django_pbn_client.get_or_download` z zachowaniem wrappera
  `zapisz_mongodb` (fetch przed transakcją persystencji)
- test blokujący zachowanie markera USUNIĘTY w __str__ 6 modeli

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Dwa miejsca normalizowały dane osobowe autora z PBN własnymi,
rozjeżdżającymi się łańcuchami preferencji:

- pbn_api/models/publication.py (_normalizuj_autora): lastName +
  firstName/givenNames/name, brak familyName;
- pbn_import/.../pbn_importuj_uid.py: familyName/lastName +
  givenNames/name, brak firstName, brak guardu na nie-dict.

Oba delegują teraz do jednego źródła prawdy — pbn_client.normalize_author_name
(unia kluczy: familyName→lastName, firstName→givenNames→name; nie-dict →
brak danych). Paczka używa None jako sentinela pustki; oba site'y koerują go
do "" (szablon rekordu i str(autorzy) w logach zakładają puste stringi, a
display-line importu składa f-string).

Zysk: rozpoznanie familyName (publication) i firstName (import) tam, gdzie
wcześniej wypadało puste; bezpieczeństwo na nie-dict w komendzie importu.
Zachowany zamrożony ""-kontrakt (test goły-UID) + nowy test familyName.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Interaktywne narzędzie diagnostyczne trzymało własne kopie logiki, którą
mamy teraz w pbn-client. Podmienione na jedno źródło prawdy:

- _extract_object_id → pbn_client.decode_publication_object_id
  (mapowanie endpoint_choice → bez_oswiadczen: "publications"=all-in-one
  → False, "repositorium" → True). Paczka przy niejednoznacznej odpowiedzi
  (lista != 1 element, zły typ) RZUCA zamiast po cichu zwracać None —
  narzędzie łapie to głośno, pokazuje surową odpowiedź i pyta usera czy
  wyjść czy jechać dalej z objectId=None (decyzja usera: rzadko używane,
  niech krzyczy i pyta).
- lokalny _key → pakietowe statement_key_pbn / statement_key_intended;
  różnice liczy diff_statements, część wspólną (której paczka nie zwraca)
  liczymy lokalnie na tych samych kluczach.

Testy: nowy test integracyjny (niejednoznaczna odpowiedź → głośny błąd +
przerwanie pod --yes-all) + unit gałęzi "kontynuuj" (zwraca None).
16 passed w suicie komendy, 339 w całym pbn_api. ruff clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…w paczce)

Rozpoznanie 422 "was not exists!" robi teraz RAZ endpoint paczki
(pbn_client.get_publication_by_id rzuca PublicationNotFound) — BPP nie
duplikuje już tej detekcji w call-site.

- pbn_api/exceptions.py: BrakIDPracyPoStroniePBN staje się aliasem
  PublicationNotFound (przypisanie, ta sama klasa, `is`) zamiast osobnej
  podklasy HttpException. Dzięki temu istniejące `except
  BrakIDPracyPoStroniePBN` (odswiez_tabele_publikacji kasujący cache;
  worker importu zwracający per-item fail) łapią wyjątek rzucany przez
  paczkę. To CO INNEGO niż BPPPublicationNotFound (brak rekordu BPP).
- pbn_integrator/utils/publications.py (_pobierz_pojedyncza_prace):
  usunięto ręczną re-detekcję markera w treści; PublicationNotFound
  propagujemy, zwykły HttpException (w tym 404) leci dalej, 500
  "Internal server error" nadal → None.

Decyzja 404 (zapisana w planie): 404 bywa przejściowy → NIE jest "brak
pracy", nie kasuje lokalnego cache'u. Ani paczka, ani BPP nie mapują 404
na PublicationNotFound.

Testy przepisane na nowy kontrakt: alias-identity, PublicationNotFound z
paczki → propagacja jako BrakID (pola HTTP zachowane), 404 ≠ BrakID, goły
422 nie jest już re-detektowany przez BPP, 500 → None.
540 passed (pbn_integrator + pbn_api), ruff clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…_to_model)

pobierz_mongodb dostaje parametr on_error sterujący zachowaniem przy błędzie
zapisu POJEDYNCZEGO rekordu do lokalnego lustra BPP (IntegrityError, zły
kształt danych itp. — po naszej stronie, nie PBN):

- "raise" (default) — fail-fast jak dotąd: pierwszy błąd propaguje i przerywa
  batch (download_pbn_objects, goła pętla save bez try/except). Zwraca None.
- "skip" — deleguje do pakietowego download_to_model: zły rekord logowany
  (pełny traceback) + liczony, import reszty kończy się. Zwraca
  DownloadResult(processed, errored). Dla masowych synchronizacji (tysiące
  rekordów), gdzie jeden zepsuty rekord nie powinien wywalać całego przebiegu.

Zachowanie domyślne bez zmian — żaden istniejący caller nie zmienia
zachowania (default "raise"). Adopcja download_to_model włączana opt-in
per-getter po decyzji. Nieznana wartość on_error → ValueError (głośno).

Etykieta progress-baru ujednolicona między trybami (fasada nie forwarduje
pbar_label). Testy: fail-fast default, skip kontynuuje+liczy, ValueError.
3 nowe + 12 istniejących mongodb_ops passed, check OK, ruff clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Trzy pliki w pbn_api były czystymi re-eksportami z pakietów PBN
(`from pbn_client.X import *`) — zbędna warstwa pośrednia po tym jak kod
klienta wyszedł na PyPI. Usunięte + repoint callerów wprost na paczkę:

- pbn_api/const.py            → callery: from pbn_client.const import ...   (22 plików)
- pbn_api/utils.py            → from pbn_client.dict_utils import ...        (2)
- pbn_api/client/transport.py → from pbn_client.transport import ...        (1)

Spójne z resztą kodu po ekstrakcji (mongodb_ops itd. już importują wprost
z pbn_client/django_pbn_client).

ZOSTAWIONE świadomie:
- pbn_api/exceptions.py — hybryda: wyjątki BPP-specific + alias
  BrakIDPracyPoStroniePBN = PublicationNotFound.
- pbn_api/models/base.py — seam pod przyszłą Fazę 3 (abstrakcyjne modele).

Czysto mechaniczne (tylko podmiana ścieżki modułu, nazwy bez zmian).
Review: fable PASS + codex SHIP (brak defektów). manage.py check OK,
pbn_api 339 passed, zero nowych naruszeń ruff. Pre-existing lint
(F401/I001/UP012 w tkniętych plikach) świadomie NIE ruszany — poza zakresem.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cztery rozproszone, kruche parsery błędów wysyłki do PBN (format_pbn_error,
parse_pbn_api_error, parse_error_details, admin exception_details) stają się
cienkimi adapterami nad jednym, wspólnym kontraktem ErrorRecord.

Rdzeń (ErrorRecord + totalne parse() + serialize() do formatu v1) mieszka w
pakiecie pbn-client (0.2.1) jako czysta, framework-niezależna wiedza o
protokole PBN. W BPP zostają wyłącznie Django-owe adaptery display. Do czasu
publikacji pbn-client 0.2.1 na PyPI, zależność jest pinowana git-source w
[tool.uv.sources] (do usunięcia po release).

Rollout reader-first (Stage 1): readery rozumieją legacy ORAZ format v1;
writery bez zmian. serialize() istnieje, ale nie jest podpięty (Stage 2).

Byte-identyczność realistycznego legacy pinowana golden testami
charakteryzacyjnymi (zdjętymi sprzed unifikacji). Świadome ulepszenia:
format_pbn_error nie rzuca już TypeError na payloadzie-liczbie; admin
exception_details porzuca hack split('"details":')[1][:-3].

Naprawy z 2× adwersaryjnej recenzji Fable: (1) readery poprawnie obsługują
blob v1 (pole `wire`; guard >512 tylko dla legacy) — bez tego Stage 1 nie
kupował ochrony przed deploy-race; (2) parse() jest totalne także na
RecursionError/OverflowError/MemoryError z wrogiego body; (3) content_json_valid
odróżnia JSON null od niepoprawnego body; (4) serialize() capuje wszystkie pola
(blob dowodliwie < 65535). Szczegóły: docs/deweloper/p4-error-record-unifikacja-spec.md §9.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Base automatically changed from feat/pbn-shims to feat/pbn-adopt-api4 July 24, 2026 14:49
Base automatically changed from feat/pbn-adopt-api4 to dev July 24, 2026 15:12
mpasternak and others added 2 commits July 24, 2026 17:16
…612)

download_disciplines/sync_disciplines przestają trzymać otwartą transakcję
przez czas remote-calla do PBN. Pobranie idzie teraz przez
sync_dictionary(fetch, upsert) (wzorzec materialize-before-atomic z
django-pbn-client 0.2.1): fetch poza transakcją, upsert atomowo. Matching do
modeli BPP (Dyscyplina_Naukowa/TlumaczDyscyplin) wydzielony do osobnej
@transaction.atomic metody — zostaje w BPP (BPP-specific).

Usunięto martwy `if discipline.name == "weterynaria": pass`. Test-strażnik
(transaction=True) dowodzi, że fetch dzieje się poza transakcją.

Zależność django-pbn-client 0.2.1 pinowana git-source (do usunięcia po
publikacji na PyPI). Stack: na feat/pbn-p4-reader.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
# Conflicts:
#	pyproject.toml
#	src/pbn_api/client/disciplines.py
#	src/pbn_api/tests/test_client_disciplines.py
#	src/pbn_export_queue/templatetags/pbn_queue_extras.py
#	src/pbn_export_queue/views/utils.py
#	uv.lock
@mpasternak
mpasternak merged commit 84689d0 into dev Jul 24, 2026
12 checks passed
@mpasternak
mpasternak deleted the feat/pbn-p4-reader branch July 24, 2026 15:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant